NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/4743

Internet Message Format | 1996-08-06 | 4.3 KB

Path: fozzie.sun3.iaf.nl!not-for-mail
From: [e-mail] (Geert Bosch)
Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
Subject: Re: Hungarian notation
Followup-To: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
Date: 31 Jan 1996 12:32:49 +0100
Organization: La Calandre Infortunee
Message-ID: <4enk11$[e-mail]>
References: <[e-mail]> <4cvu68$[e-mail]> <4d21og$[e-mail]> <4d2ok0$[e-mail]> <[e-mail]> <4e5k6o$[e-mail]> <4ej0ds$[e-mail]> <[e-mail]>
NNTP-Posting-Host: fozzie.sun3.iaf.nl
X-Newsreader: TIN [version 1.2 PL2]

In article <[e-mail]> you wrote:
: Maybe not.  But not everything falls under the hood of data abstraction.
: Somebody has to create the module/ADT/package/class first, and a good way
: to maintain it is to use a typedef or equivalent.  There are my 2c.

It's not a good way to do it that way. It's something like "I'm using the
name My_ADT, but I *know* it's unsigned long, so when I need to I just
break the abstraction". So you're just hiding the implementation details
a little and the original writer of the ADT never knows if someone depends
on certain internals.

If you really want to break things that way in Ada, you can use an
'Unchecked_Conversion' which is about the same as a typecast in C.
However, when most Ada-programmers (including me) read code they'll go
in alert-mode when they encounter 'with Unchecked_Conversion' at the
top of your package. When they see you're using it to break the ADT,
your code will be labeled as not maintainable: if the implementation is
being changed, your package will be broken. When the size of the ADT
remains the same, you might not even notice it, except of course for
run-time problems.

So, what's the right way to do this? If you're the maintainer of
the code and need to change it and you don't have to change the
interface and the changed implementation is consistent with the
specifications in all regards, then you just change the original
package implementation. Since that's the only place that is dependend
on the internals of the ADT you'll not break anything else.

But what if this isn't the case, or if you don't have access to
the source? When the ADT is a tagged abstract data type, you can
extend it and override existing operations on the type. As long
as you don't have to switch between implementations at *runtime*,
you do not have the overhead of dispatching calls. This is one of
the reasons to implement ADT's with tagged types when extension
is important.

If the ADT is not a tagged type and you cannot change the
implementation of the original type (because it doesn't conform
to the old specs for example) the best way to solve the problem
is by implementing a child package of the original parent package.
That way you can view the internals of the ADT and create a new
ADT based on the original one. Of course when the parent changes
the implementation, the child needs to be changed too. The
difference is however that the compiler will catch any inconsistencies
which might go unnoticed when using C type-casts or unchecked
conversions.

For all methods described above you'll not silently break any
existing code. If you think that the scheme above is too
complicated for that goal, think about this: if your package
specification is good, you'll only change the implementation. Period.

When you need to change the interface and all code depending on the ADT
is under your control (one person or small team developing software),
you just change the specification and make any changes that are needed
in packages using the ADT.  The compiler will help you doing this by
catching all type inconsistencies that may arise.

The only place were the other methods make much sense is when
the code is used in large projects or when the code is used in
many projects and has a long life-time. In these cases silently
breaking code when changing the specification is unacceptable, and
hunting through all code depending on the ADT for implementation
dependencies is not feasible. These are the places were type-extension
and package-extension are important.

Greetings,
   Geert

--
E-Mail: [e-mail]
 Phone: [phone]